Object interconnections גרא וייס המחלקה למדעי המחשב אוניברסיטת בן-גוריון

Size: px

Start display at page:

Download "Object interconnections גרא וייס המחלקה למדעי המחשב אוניברסיטת בן-גוריון"

Marian Atkinson
6 years ago
Views:

1 Object interconnections גרא וייס המחלקה למדעי המחשב אוניברסיטת בן-גוריון

2 2 Roadmap In this chapter we move up a level of abstraction, and consider collections of objects working together Our focus will be on how objects are connected to each other, and how one can make those connections as loose as possible Our primary tool for analyzing connectedness will be the concepts of visibility and dependency

3 Connections - The Bane of Large Scale Programming Difficulties in developing large scale programs are often not so much a matter of algorithmic complexity As they are of communication

3 3 Connections - The Bane of Large Scale Programming Difficulties in developing large scale programs are often not so much a matter of algorithmic complexity As they are of communication complexity: If several programmers are working together on a project and need to control the amount of information One programmer must have knowledge about the code being developed by a second programmer

you can't name something, you can't manipulate it Languages already have a variety

4 4 Visibility Visibility is an attribute of names: Names of variables, functions, fields, whatever Mark Visibility type + Public # Protected - Private ~ Package If you can't name something, you can't manipulate it Languages already have a variety of mechanisms for the control of name visibility OOP languages introduce a few new twists

5 5 Dependency Dependency describes the degree to which one software component relies on another component to perform its responsibilities A high degree of dependency obviously limits code reuse - moving one component to a new project

components Cohesion refers to the extent to which the actions of a component seem

6 6 Coupling and Cohesion Coupling refers to the extent to which one component uses another to perform actions Generally a goal is to reduce coupling between software components Cohesion refers to the extent to which the actions of a component seem to be tied together Generally a goal is to increase cohesion within a software component

7 7 Varieties of Coupling Arranged from Bad to Better: Internal data coupling Global data coupling Control (or sequence) coupling Component coupling Parameter coupling Subclass coupling

8 8 Internal Data Coupling class SneekyModifier { public: void sneeky () { // change my friends name myfriend->name = "Lucy"; Person * myfriend; ; class Person { public: Person () { name = "Larry"; string name; ; This is bad because it makes it difficult to understand a single class in isolation Can be mitigated by always making your data areas private or protected, and not exposing pointers to these areas

9 9 Global Data Coupling double todaysdow; class One { public: void setdow () { todaysdow = 9473; ; class Two { public: void printdow () { cout << "Today the Dow hit " << todaysdow; ; Two or more classes that interact through a common global variable Again, makes it difficult to understand a single class in insolation Can be mitigated by making a class that manages the global area, thereby reducing global coupling to component coupling

10 10 Control, or Sequence Coupling This occurs when objects are linked by the fact that one must be manipulated before the other, but otherwise they have no connection Again, makes it difficult to understand a class in isolation Can be mitigated by making a controller class, that clearly indicates the sequence of operations: class MyClass { public: dostuff () { dofirst(); dosecond(); protected: dofirst() {... dosecond() {...

11 11 Component Coupling Occurs when one class holds an instance of another class: class Set {... private: List data; Ideally, connection is one way Held component has no knowledge of holder This is a very weak and benign connection (weak is good)

12 12 Parameter Coupling Parameter coupling occurs when one object knows of another only through being passed as a parameter or a return value Another very weak (and therefore good) type of coupling class MyClass { public: void dosomething (Set aset) {...

13 13 Subclass Coupling Subclass coupling describes the relationship between a parent class and a child class Ideally the parent has no strong connection to the child, so the connection is one way Can understand the parent in isolation from the child class Parent {... class Child extends Parent {... A very weak form of coupling. Which makes it a good design choice

14 14 Varieties of Cohesion Also arranged from bad to better: Coincidental cohesion Logical cohesion Temporal cohesion Communication cohesion Sequential cohesion Functional cohesion Data cohesion

15 15 Coincidental cohesion Coincidental cohesion is the lowest form of cohesion found in object oriented software development Methods appear to have been placed there randomly or without consideration of the proper concern of the method: public static class Utils { // A utility method that helps out with error logging. public static void LogError(String msg) { MyLogger logger = new MyLogger(); // Create instance of logger class logger.logit(msg); // A utility method that displays a message to the user. public static void ShowMsg(String msg) { MessageBox.Show(msg); This type of class necessarily leads to tight coupling as its varied functionality is used in many places

16 16 Logical Cohesion All elements of the module perform similar operations: Error handling, data input, data output, etc. An example of logical cohesion: A set of print functions to generate an output report arranged into a single module A crucial point is that only a specific subset of the functions is used in a specific context In general, logically cohesive modules should be avoided, if possible

17 17 Temporal cohesion A temporally cohesive module is one whose elements are functions that are related in time Example: Consider a module called On_Really_Bad_Failure that is invoked when a Really_Bad_Failure happens The module performs several tasks that are not functionally similar or logically related, but all tasks need to happen at the moment when the failure occurs.: cut power to all assembly line machines notify the operator console of the failure make an entry in a database of failure records

18 18 Communication cohesion A communicationally cohesive module is one which performs several functions on the same input or output data For example: Obtain author, title, or price of book from bibliographic record, based on a passed book identifier The functions in this example could be performed independently of each other and should be separated for greater flexibility Maintainability is usually improved when you separate a communicationally cohesive module into functionally cohesive modules.

19 19 Sequential cohesion A sequentially cohesive module contains activities where output data from one activity serves as input data to the next activity Examples of activities in a sequentially cohesive module are: retrieve customer, retrieve customer order, and generate invoice Strength of Sequential Cohesion Good coupling Easy to maintain Weakness of Sequential Cohesion Not as good candidates for re-use as are functionally cohesive modules The activities contained within the sequentially cohesive module generally only meet the requirements of that one module

20 20 Functional cohesion A functionally cohesive module performs one and only one problem related task. Examples of functionally cohesive modules are: Drag Drop an event triggered when a dragged object is dropped on a window Sum Elements in Array Convert Kilometers to Miles Read Customer Record Calculate Net Pay Assign Account Number Functionally cohesive modules may be simple and perform one task However, a complex module with numerous sub-modules may still be functionally cohesive if all of its subordinate modules are only performed to carry out the task of the parent module For example: Calculate Net Pay is functionally cohesive although it contains many different functions (e.g., calculate taxable deductions, calculate tax, calculate CPP deduction)

21 21 Data Cohesion Elements cooperate to present an interface to a hidden data structure: Stack Windows Communication Protocol Data Base Employee

22 22 Limiting Coupling The Law of Demeter The law of Demeter is an attempt to limit the way in which one component can interact with another component: In a method M attached to a class C, only methods defined by the following classes may be used: 1. The instance variable classes of C 2. The argument classes of method M (including C); Note that global objects or objects created inside the method M are considered arguments to M

23 23 Rewritten in terms of messages Law of Demeter (weak form). Inside a method, it is only permitted to access or send messages to the following objects: 1. The arguments associated with the method being executed (including the self object) 2. Instance variables for the receiver of the method 3. Global variables 4. Temporary variables created inside the method.

24 24 What is ruled out Basically, what is ruled out by the law of Demeter is one object going in and directly manipulating the internal data values of another object Instead, all access to data values in another component should be made through procedures - thereby reducing data coupling to the weaker parameter coupling Classes can be studied and understood in isolation from one another!

25 25 Class-Level versus Object-Level Visibility Here is another interesting way that objectoriented languages have chosen to differ from each other: Question: Are sisters and brothers allowed to look at each others private data fields? An answer of YES is class-level visibility (C++ and Java) And answer of NO is object-level visibility (Smalltalk)

26 26 Active Values A good illustration of why parameter coupling is better than direct manipulation Suppose we have an existing program and we just want to observe a data value - see when it gets set and changed Solution - create a new subclass that just changes those methods that set or read the data Reactor : Object { double heat;... - (void) setheat: (double) newvalue; - GraphicalReactor : Reactor - (void) setheat: (double) newvalue { /* code necessary to */ /* update gauge */ [ super setheat: newvalue Can add new functionality simply by replacing an object with an instance of a subclass; making no change to the original class

27 27 Public, Subclass and Private Faces We have noted several times that object have a public and private face - inheritance introduces a third alternative, the subclass face: Public features are those aspects that users of the software component must have access to. Private features are those aspects that the implementor of the software component must have access to Protected features are those aspects that implementors of child classes can have access to There are two types of clients for the class developer: User clients (those who use an instance of the class) Subclass clients (those who will subclass from the class)

28 28 Control of Visibility The public/protected/private modifiers are the primary way to control visibility in most OO languages There are other mechanisms as well: Friends in C++ Inner classes in Java and C++ Private Inheritance in C++ (inheritance for construction) Name Spaces, Units or Packages

29 29 Friends in C++ In C++ a friend (class or method) is allowed access to all parts of a class: class Complex { public: Complex(double, double); friend double abs(complex&); private: double rp; double ip; ; double abs(complex& x) { return sqrt(x.rp * x.rp + x.ip * x.ip); Friendship is something that is given away, not something that is taken

30 30 Inner Classes Inner classes in Java and, to a lesser extent, nested classes in C++ and C# are allowed to access the data areas in the surrounding class: class AContainerClass {... // return an enumerator public Enumeration elements() { return new MyEnumeration();... // inner class is allowed to see // all aspects of surrounding class private class MyEnumeration implements Enumeration {... public boolean hasmoreelements () {... public Object nextelement() {... Uses a lot for event listeners in Java, among other things

31 31 Private Inheritance in C++ In a public inheritance the public features of a parent become public features of a child In a private inheritance, the public and protected features of the parent do not filter through the child; and only the public features of the child are visible The child class does not subscribe to the is-a rule We called this Inheritance For Construction

32 32 Name Spaces, Packages or Units Names Spaces (C++), Packages (Java) or Units (Delphi and Object Pascal) give the programmer another way to encapsulate names, and release only those names that are necessary: package foo; public class bar { // will be visible... class baz { // will not be visible outside package...

33 33 Intentional Dependency Sometimes want code to depend upon another class Sometimes want this even if the dependee doesn't know the dependant (example, a model and its display). Can be managed by having a separate dependency manager When an object changes, it tells the manager notify my depedants

34 34 Chapter Summary In this chapter we have examined a variety of topics related to dependency: How classes and objects can depend upon each other How methods within a class can depend upon each other How to control visibility, as a means of controlling dependency How strong dependency can be weakened by using alternative designs

Object interconnections

Object interconnections 2 Roadmap In this chapter we move up a level of abstraction, and consider collections of objects working together Our focus will be on how objects are connected to each other, and